Google의 신규 개발자 신원 확인 의무화 정책에 따른 기업 Android 앱 관리 전략 로드맵

1. 구글의 정책

구글이 2026년까지 모든 안드로이드 앱 개발자의 신원 확인을 의무화하는 새로운 정책은 단순한 규정 준수 업데이트가 아니다. 이는 익명으로 기업용 앱을 배포하던 시대의 종말을 고하는 근본적인 패러다임의 전환이다. 이 정책은 기업들이 비공식적인 APK 직접 배포 방식을 폐기하고, 안드로이드 엔터프라이즈(Android Enterprise) 프레임워크를 전면적으로 수용하도록 강제한다.

이러한 변화는 새로운 절차적, 기술적 요구사항을 수반하지만, 동시에 기업의 모바일 전략을 한 단계 성숙시킬 전략적 기회를 제공한다. 관리를 중앙화하고, 배포를 자동화하며, 보안을 강화함으로써 조직은 잠재적 위험을 크게 줄이고 운영 효율성을 향상시킬 수 있다.

따라서 2026년 9월 마감 시한 이전에 규정을 준수하고 전략적 우위를 확보하기 위한 선제적인 대응이 필수적이다. 본 안내서에 제시된 로드맵은 이러한 전환을 위한 단계별 접근법을 제공한다. 핵심 조치로는 D-U-N-S 번호의 즉각적인 확보, 개발자 계정의 통합, Play App Signing으로의 전환, 그리고 EMM/MAM 및 CI/CD 파이프라인으로의 앱 배포 완전 통합 등이 있다.

본 안내서는 다음의 세 가지 핵심 전략을 상세히 기술한다.

1. 기술 및 운영 개편: 개발자 신원을 중앙에서 관리하고, Managed Google Play를 통해 안전한 EMM 기반 배포 모델로 전환한다.
2. 프로세스 재설계: Google Play Developer Publishing API를 활용한 자동화를 통해 새로운 규정 준수 및 배포 단계를 DevOps 수명주기에 통합한다.
3. 전략적 재정비: 이번 정책을 지렛대 삼아 Apple의 기업용 앱 모델에 필적하는 보안 태세를 갖춤으로써, 안드로이드를 비즈니스 핵심 애플리케이션을 위한 안전하고 관리 가능한 플랫폼으로 격상시킨다.

2. 새로운 의무: 구글 개발자 신원 확인 정책 심층 분석

이 섹션에서는 구글의 새로운 정책, 그 범위, 그리고 이면에 깔린 전략적 동기를 심층적으로 분석하여, 후속 분석과 로드맵의 기초를 마련한다.

2.1 정책 심층 분석: 신원 확인 요구사항의 해부

새로운 정책의 핵심은 개발자 계정의 유형에 따라 구체적이고 엄격한 정보를 요구하는 데 있다. 특히 기업의 경우, ‘개인’ 계정이 아닌 ‘조직’ 계정 사용이 사실상 강제된다.

조직 계정 신원 확인: Play Console 문서에 명시된 ‘조직’ 개발자 계정의 필수 정보는 다음과 같다.1

• 법적 이름 및 주소: Google Play에 공개적으로 표시된다.
• 확인된 연락처 전화번호 및 이메일 주소: 마찬가지로 공개적으로 표시된다.
• 비공개 연락처 정보: 구글이 연락할 목적으로만 사용되는 별도의 전화번호와 이메일 주소가 필요하다.
• 공식 조직 문서: 정부, 사업자 등록 기관 등 신뢰할 수 있는 기관이 발행한 공식 문서 제출이 요구된다.
• D-U-N-S 번호: 조직 계정의 결제 프로필 생성에 필수적인 요소로, Dun & Bradstreet를 통해 발급받아야 한다. 이 과정은 30일 이상 소요될 수 있으므로 가장 먼저 준비해야 할 항목이다.1

개인 계정과 조직 계정: 정책상 개인 개발자는 개인 계정을 사용할 수 있지만, 법적 이름과 주소 같은 개인 정보가 공개된다는 점에서 기업 소속 개발자에게는 현실적으로 부적합하다.4 따라서 모든 기업의 앱 개발 및 배포 활동은 ‘조직’ 계정을 통해 이루어져야 한다. 이 결정은 전체 규정 준수 프로세스의 방향을 결정짓는 첫 단추다. 전체 신원 확인 절차는 결제 프로필에 의존하고, 조직의 결제 프로필은 D-U-N-S 번호를 요구한다. 즉, D-U-N-S 번호 확보는 기술적 과제 이전에 선행되어야 할 비즈니스 프로세스이며, 이 단계에서 발생하는 지연은 전체 규정 준수 일정을 위협하는 심각한 병목 현상을 초래할 수 있다.

2.2 생태계 전반의 영향: Play Store를 넘어서

이번 정책의 가장 파괴적인 측면은 그 영향력이 Google Play Store에 국한되지 않는다는 점이다.

익명 사이드로딩의 종말: 이 정책은 제3자 앱 스토어나 직접적인 사이드로딩을 포함하여 모든 인증된 안드로이드 기기에 앱을 배포하는 개발자에게 적용된다.4 이는 기업이 내부 서버에 APK 파일을 호스팅하거나 이메일로 배포하던 전통적인 사내 앱 배포 방식을 더 이상 유효하지 않게 만든다.5 과거에는 안드로이드의 개방성이 내부 앱을 손쉽게 사이드로딩할 수 있는 ’기능’으로 여겨졌지만, 이제는 공식적으로 관리해야 할 ’책임’으로 전환되었다. 모든 배포 채널을 합법화하고 추적 가능하게 만들어야 하는 것이다.

단계적 글로벌 시행: 정책은 전 세계적으로 단계별로 시행될 예정이다. 2026년 9월까지 브라질, 인도네시아 등 특정 지역을 대상으로 첫 단계가 시행되며, 2027년에는 전면적인 글로벌 적용이 이루어진다.4 기업은 자사의 글로벌 운영 범위를 고려하여 가장 이른 적용 시점에 맞춰 계획을 수립해야 한다.

2.3 전략적 배경: 구글의 최종 목표

구글이 이처럼 강력한 정책을 추진하는 데에는 명확한 전략적 목표가 있다.

악성코드 차단 및 신뢰 강화: 구글은 익명성 뒤에 숨어 활동하는 악의적인 행위자들에 의한 악성코드, 사기, 데이터 도용을 근절하는 것이 정책의 주된 목표라고 명시했다.4 실제로 사이드로딩을 통해 전달되는 악성코드는 Google Play를 통한 경우보다 50배 이상 많다는 자체 데이터는 이 정책의 핵심적인 정당성을 뒷받침한다.

플랫폼 동등성 및 기업 시장 경쟁력 확보: 이 조치는 안드로이드의 기업용 앱 배포 모델을 Apple의 고도로 통제된 ‘사용자 설정 앱(Custom App)’ 프레임워크와 유사한 수준으로 끌어올린다.6 개발자 신원 확인을 강제하고 관리 채널을 통한 배포를 유도함으로써, 구글은 오랫동안 지적되어 온 iOS 대비 안드로이드의 보안 취약점이라는 기업 시장의 우려를 정면으로 해결하고자 한다.8

규제 환경과의 정렬: 이 정책은 디지털 플랫폼에 더 엄격한 추적성과 책임성을 요구하는 EU의 디지털 서비스법(DSA)과 같은 글로벌 규제 동향에 부합한다. Apple 역시 EU에서 유사한 조치를 이미 시행한 바 있어 4, 이는 검증된 디지털 신원을 요구하는 더 넓은 산업 트렌드의 일부임을 시사한다.

3. 기술 및 운영 로드맵: 안전한 관리형 프레임워크로의 전환

이 섹션에서는 IT 및 개발팀이 실제 전환을 수행하기 위한 핵심적이고 실행 가능한 기술 로드맵을 단계별로 제시한다.

3.1 1단계: 기반 규정 준수 및 계정 통합 (현재 ~ 2025년 2분기)

조치 1: 중앙화된 조직 개발자 신원 확립

• 전사 조직을 대표하는 단일 마스터 Google Play 개발자 계정을 생성해야 한다. 이 계정은 개별 개발자나 부서가 아닌 중앙 IT 또는 DevOps 거버넌스 팀이 소유하고 관리해야 한다.
• D-U-N-S 번호 신청을 시작으로 즉시 신원 확인 절차를 완료한다.1
• Play Console 내의 역할 기반 접근 제어(RBAC) 기능을 활용하여 개발팀에 특정 앱에 대한 관리 권한을 부여한다. 이를 통해 마스터 계정의 전체 소유권을 넘기지 않고도 필요한 작업을 수행할 수 있도록 통제한다.9

조치 2: Play App Signing을 통한 앱 서명 현대화

• 모든 신규 및 기존 사내 앱에 대해 Play App Signing 사용을 의무화해야 한다. 이는 최종 앱 서명 키를 안전하게 보관하고 관리하는 책임을 구글의 보안 인프라로 이전하는 조치다.11
• 이 모델에서 개발자는 업로드 키로 빌드를 서명하게 된다. 이 업로드 키는 유출 시에도 사용자 기기에 설치된 앱의 정체성에 영향을 주지 않고 무효화 및 재발급이 가능하다. 이는 개별 키스토어 파일을 직접 관리하는 기존 방식에 비해 보안 및 운영 측면에서 비약적인 발전을 의미한다.
• 안드로이드 앱의 정체성은 서명 키와 직결된다. 키를 분실하면 기존 앱에 대한 업데이트를 게시할 수 없으며, 새로운 패키지 이름으로 새 앱을 만들어 모든 사용자에게 재배포해야 하는 재앙적인 상황에 직면한다.12 Play App Signing은 이러한 실존적 위협을 원천적으로 차단하므로, 더 이상 선택 사항이 아닌 기업 모바일 전략의 핵심 구성 요소로 간주해야 한다.

3.2 2단계: EMM 기반 배포 워크플로우 설계 (2025년 3분기 ~ 2026년 1분기)

조치 3: APK 직접 배포에서 Managed Google Play로 전환

• 새로운 표준 워크플로우: 모든 사내 앱은 Play Console을 통해 ’비공개 앱’으로 게시되어야 한다. 이 과정은 EMM 콘솔 내에서 직접 수행할 수 있으며, 이 경우 $25의 등록비가 면제되고 기업을 대신하여 자동으로 Play Console 계정이 생성되는 등 절차가 간소화된다.13
• 기술적 워크플로우:

1. 개발자는 조직의 마스터 계정을 통해 서명된 앱 번들(AAB) 또는 APK를 Play Console에 업로드한다.
2. 앱 설정에서 출시 > 설정 > 고급 설정 > Managed Google Play 탭으로 이동한다.15
3. 배포 목록에 회사의 ’조직 ID’를 추가한다. 조직 ID는 회사의 안드로이드 엔터프라이즈 인스턴스를 식별하는 고유 ID로, EMM 콘솔에서 확인할 수 있다.14
4. 게시가 완료되면 해당 앱은 조직 내 사용자에게만 기기의 Managed Google Play 스토어를 통해 표시된다.
5. EMM 관리자는 Microsoft Intune, Scalefusion 등의 EMM 콘솔을 사용하여 앱을 기기에 자동으로 설치하거나, 사용자 그룹에 할당하거나, 업무 프로필 내 Play Store에서 선택적으로 설치할 수 있도록 지정할 수 있다.17

조치 4: 테스트 트랙 및 타겟 배포를 통한 세분화된 제어 구현

• Play Console 내 비공개 테스트 트랙(알파/베타)을 활용하여 정식 출시 전 QA팀이나 파일럿 사용자 그룹과 같은 특정 사용자에게 사전 출시 버전을 배포한다.14
• 복잡한 조직 구조를 가진 기업의 경우, 단일 비공개 앱을 최대 1,000개의 여러 조직 ID에 배포하는 기능을 활용할 수 있다. 이는 지역, 자회사 또는 개발/스테이징/운영 환경별로 별도의 EMM 인스턴스를 운영하는 기업에 이상적인 해결책이다.15
• 과거 내부 APK에 대한 접근은 다운로드 링크에 접근할 수 있는 사람에 의해 통제되었으나, 이는 취약한 보안 모델이다. 새로운 모델에서는 비공개 앱의 대상을 정의하는 메커니즘이 EMM에 등록된 기업과 연결된 ’조직 ID’로 대체된다.15 따라서 Play Console 내 조직 ID 목록에 대한 통제는 앱 배포의 마스터 제어 장치가 되며, 이는 접근 제어를 중앙화하고 대폭 강화하는 핵심적인 변화다.

표 1: 실행 로드맵 및 타임라인

4. 프로세스 재설계: 새로운 정책의 DevOps 수명주기 통합

이 섹션에서는 변화에 따른 인력 및 프로세스 측면을 다루며, 개발 및 운영 워크플로우를 새로운 현실에 맞게 조정하는 방법에 초점을 맞춘다.

4.1 규정 준수 및 배포 자동화: CI/CD 파이프라인

수동 작업으로 인한 부담을 피하기 위한 핵심은 자동화에 있으며, Google Play Developer Publishing API가 그 열쇠다. 이 API는 Play Console에서 수행할 수 있는 거의 모든 작업을 자동화할 수 있게 해준다.10

자동화된 파이프라인 청사진:

1. 커밋 및 빌드: 개발자가 코드를 리포지토리에 커밋하면, CI 서버(예: Jenkins, GitLab CI)가 빌드를 트리거하여 업로드 키로 서명된 AAB를 생성한다.
2. ‘Edit’ 생성: CI 스크립트가 Publishing API에 인증하고 변경 사항을 적용하기 위한 트랜잭션 세션인 새로운 ’edit’을 생성한다.21
3. 업로드 및 할당: 스크립트는 새로운 AAB를 해당 edit에 업로드하고, 이를 internal, alpha, production 등 원하는 트랙에 할당한다.10
4. 리스팅 업데이트 (선택 사항): 동일한 edit 내에서 릴리스 노트나 기타 메타데이터를 업데이트할 수도 있다.
5. ‘Edit’ 커밋: 스크립트가 edit을 커밋하면, 새로운 릴리스가 구글의 검토를 위해 제출된다. 이는 원자적(atomic) 작업으로, 모든 변경 사항이 한 번에 적용된다.21
6. EMM 동기화: 앱이 승인되고 게시되면, EMM 플랫폼은 Managed Google Play와 자동으로 동기화하여 자체 정책(예: 강제 업데이트, 사용자 확인 후 업데이트)에 따라 업데이트를 배포한다.17

이러한 CI/CD 통합 22은 여러 단계로 복잡해진 새로운 프로세스를 개발자에게는 ‘원클릭’ 작업처럼 매끄럽게 전환시킨다. 수동으로 수십, 수백 개의 앱 업데이트를 관리하려는 시도는 운영 병목과 인적 오류를 유발할 수밖에 없으므로, Publishing API를 통한 자동화는 확장성을 확보하기 위한 유일하고 현실적인 경로다.

4.2 거버넌스 및 내부 가이드라인 개정

신규 개발자 온보딩 프로세스: 안드로이드 앱을 개발하는 모든 개발자는 중앙 Play Console 계정에 적절하고 제한된 권한으로 추가되어야 한다. 이들의 작업 흐름은 중앙 업로드 키와 CI/CD 파이프라인을 사용하는 것을 원칙으로 해야 한다.

개정된 기술 가이드라인: 다음 내용을 포함하는 문서를 작성하고 전파해야 한다.

• APK 직접 배포 방식의 공식적인 폐기.
• Play Console에 새로운 비공개 앱 설정을 요청하는 절차.
• 업데이트 릴리스를 위한 CI/CD 파이프라인 사용 방법.
• 각 앱의 Play Console ‘데이터 보안’ 섹션 작성 가이드라인. 이는 데이터 처리 방식에 대한 의무적인 선언이다.24 이 데이터 보안 양식 작성 의무는 비공개 앱에도 적용될 가능성이 높으며, 이는 숨겨진 규정 준수 과제다. 모든 사내 앱에 대해 수집하는 사용자 데이터, 사용 방식, 암호화 여부 등을 공식적으로 문서화하고 공개해야 하므로 법무 및 개인정보보호팀의 검토가 필요할 수 있다.

직원 대상 커뮤니케이션 및 교육: 최종 사용자는 새로운 앱 배포 방식에 대해 교육받아야 한다. 더 이상 웹사이트에서 APK를 다운로드하는 것이 아니라, 업무 프로필 내 Play Store에서 회사 앱을 찾게 될 것이다. 이러한 변화는 혼란과 지원 요청을 줄이기 위해 명확하게 전달되어야 한다.

표 2: 프로세스 전환 매트릭스: 기존 방식 vs. 새로운 워크플로우

5. 전략적 분석 및 장기 전망

이 마지막 섹션에서는 논의의 수준을 실행 세부사항에서 전략적 함의로 끌어올려, 경영진에게 미래 지향적인 관점을 제공한다.

5.1 보안 태세 비교: 안드로이드 vs. Apple의 기업 모델

구글의 새로운 정책은 안드로이드와 Apple의 기업용 앱 배포 모델 간의 격차를 크게 좁혔다.

Apple의 모델:

• 개발자 확인: Apple Developer Enterprise Program 등록 시 유사한 조직 확인 절차를 요구한다.
• 앱 제출 및 검토: ’사용자 설정 앱(Custom Apps)’은 App Store Connect를 통해 제출되며, 공개 앱과 동일한 앱 검토 프로세스를 거친다.7
• 배포: 앱은 Apple Business Manager(ABM) 또는 Apple School Manager(ASM)에서 특정 조직 ID를 대상으로 비공개로 제공된다.6
• 설치: 조직의 MDM 솔루션이 ABM/ASM에 연결되어 라이선스를 구매(무료 앱 포함)하고 관리 기기에 배포하는 데 사용된다.26

직접 비교:

• 신원 확인: 이제 두 플랫폼 모두 엄격한 조직 신원 확인을 요구한다.
• 검토: 두 플랫폼 모두 비공개/사용자 설정 앱을 공식적인 검토 프로세스에 따라 플랫폼 가이드라인 준수 여부를 확인한다.
• 배포: 두 플랫폼 모두 조직 ID와 연결된 중앙화된 비공개 리포지토리(Managed Google Play vs. ABM Custom Apps)를 사용한다.
• 설치: 두 플랫폼 모두 최종 전달 메커니즘으로 EMM/MDM 솔루션에 의존한다.

결론적으로, 새로운 안드로이드 모델은 보안, 추적성, 관리 용이성 측면에서 Apple 모델과 기능적으로 동등한 수준을 달성했다. 이제 주요 차별점은 배포 채널 자체의 보안이 아니라, OS의 근본적인 아키텍처와 기기 다양성에 있다.8 기업용 앱 배포 채널의 보안성이 두 플랫폼 간에 사실상 상향 평준화됨에 따라, 플랫폼 선택 기준은 하드웨어 비용, 사용자 선호도, 특정 EMM 기능 등 다른 요인으로 이동하게 될 것이다.

표 3: 기능별 비교: 안드로이드 vs. Apple 기업용 앱 배포

5.2 기업 시장에서의 안드로이드의 미래

’개방성’의 재정의: 이 정책은 안드로이드 철학의 성숙을 의미한다. ’개방성’은 ’제한 없음’에서 ‘유연하지만 책임감 있는’ 방향으로 진화하고 있다. 개발자는 여전히 배포 방법을 선택할 수 있지만 5, 더 이상 익명으로 활동할 수는 없다. 이는 보안에 민감한 기업들이 안드로이드를 신뢰하고 채택하도록 만들기 위한 필수적인 트레이드오프다.

경쟁력에 미치는 영향: iOS의 핵심적인 기업 보안 우위 중 하나를 무력화함으로써, 구글은 안드로이드를 회사 소유 기기 배포에 있어 더욱 매력적인 선택지로 만들고 있다. 하드웨어 선택의 폭, 가격 유연성, 그리고 이제는 강력하고 안전한 앱 관리 프레임워크의 결합은 기업 시장에서 안드로이드의 입지를 강화할 것이다.

장기 전망: 이 정책은 관리되지 않고 검증되지 않은 소프트웨어가 기업이든 소비자든 주류 안드로이드 생태계에서 설 자리가 없어지는 미래의 전조다. 구글은 Play Console과 안드로이드 엔터프라이즈 내에서 더 세분화된 제어, 향상된 보안 보고, 심화된 EMM 통합 등 기업용 기능을 지속적으로 확장할 것으로 예상된다. 플랫폼 전체가 공개 앱 배포뿐만 아니라 모든 사용 사례에 대해 ‘기본적으로 안전한(secure by default)’ 자세로 전환하고 있다.

6. 결론 및 실행 계획 요약

구글의 개발자 신원 확인 정책은 기업 환경에서 안드로이드의 분수령이 되는 사건이다. 완전히 관리되고 검증된 앱 생태계로의 전환은 더 이상 선택이 아닌 의무다.

조직은 이를 규제 준수의 부담으로 여길 것이 아니라, 모바일 애플리케이션 수명주기를 현대화하고, 보안을 강화하며, 거버넌스를 개선하는 촉매제로 활용해야 한다.

성공적인 전환을 통해 기업은 모바일 운영의 위험을 제거하고, 안드로이드 기기들을 iOS와 동등한 보안 및 관리 수준으로 격상시킬 수 있다. 이는 플랫폼으로부터 더 큰 가치와 잠재력을 이끌어내는 전략적 이득으로 이어질 것이다.

긴급 실행 계획:

1. 즉시: D-U-N-S 번호 획득 절차를 시작하라.
2. 단기 (향후 6개월): 중앙화된, 검증된 조직용 Play Console 계정을 구축하고, Play App Signing으로의 전환을 의무화하라.
3. 중기 (6-18개월): 새로운 EMM 기반 배포 워크플로우를 설계 및 시험하고, Play Publishing API를 CI/CD 파이프라인에 통합하기 시작하라.

7. 참고 자료

1. Verifying your Play Console developer account (for accounts …, https://support.google.com/googleplay/android-developer/answer/14177239?hl=en
2. Verify your developer identity information - Play Console Help - Google Help, https://support.google.com/googleplay/android-developer/answer/10841920?hl=en
3. Google Play Console Account Verification - Help | Uscreen, https://help.uscreen.tv/en/articles/9977039-google-play-console-account-verification
4. Google to require identity verification for all Android app developers starting 2026, https://www.storyboard18.com/digital/google-to-require-identity-verification-for-all-android-app-developers-starting-2026-79608.htm
5. Alternative distribution options | Branding & Marketing - Android Developers, https://developer.android.com/distribute/marketing-tools/alternative-distribution
6. Volume Purchase and Custom Apps - Support - Apple Developer, https://developer.apple.com/support/volume-purchase-and-custom-apps/
7. Distribute Custom Apps to Apple devices, https://support.apple.com/guide/deployment/distribute-custom-apps-dep0113f6e18/web
8. iOS vs Android: A Comprehensive Look at Security - McAfee, https://www.mcafee.com/learn/ios-vs-android-security/
9. Get Started Publishing Enterprise Apps - Managed Google Play Help, https://support.google.com/googleplay/work/answer/10637198?hl=EN
10. Google Play Developer APIs | Other Play guides - Android Developers, https://developer.android.com/google/play/developer-api
11. Use Play App Signing - Play Console Help - Google Help, https://support.google.com/googleplay/android-developer/answer/9842756?hl=en
12. App signing | Android Open Source Project, https://source.android.com/docs/security/features/apksigning
13. Support private apps | Google Play EMM API, https://developers.google.com/android/work/play/emm-api/private-apps
14. Distribute Apps | Android Management API - Google for Developers, https://developers.google.com/android/management/apps
15. Distribute private apps - Android Enterprise Help - Google Help, https://support.google.com/work/android/answer/9495634?hl=en
16. Organize managed Google Play accounts enterprises, https://support.google.com/googleplay/work/answer/7042126?hl=en
17. Add Managed Google Play apps to Android Enterprise devices with Intune, https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-add-android-for-work
18. Get Started: Android EMM - JumpCloud, https://jumpcloud.com/support/get-started-android-emm
19. Android EMM Solution | Android Enterprise Mobility Management - Scalefusion, https://scalefusion.com/android-emm-solution
20. Publishing overview | Google Play Console, https://play.google.com/console/about/publishingoverview/
21. Google Play Developer API | Google for Developers, https://developers.google.com/android-publisher
22. Continuous Integration basics | Test your app on Android, https://developer.android.com/training/testing/continuous-integration
23. Automating API delivery with CI/CD pipelines | Google Cloud Blog, https://cloud.google.com/blog/products/api-management/automating-api-delivery-with-cicd-pipelines
24. Provide information for Google Play’s Data safety section - Play Console Help, https://support.google.com/googleplay/android-developer/answer/10787469?hl=en
25. Learn about Custom Apps in Apple Business Manager, https://support.apple.com/guide/apple-business-manager/learn-about-custom-apps-axm58ba3112a/web
26. Choosing a Distribution Method — Deployment and Management Tutorials - Documentation, https://it-training.apple.com/tutorials/deployment/dm170/
27. Distributing custom app using Apple Business Manager - Stack Overflow, https://stackoverflow.com/questions/75765373/distributing-custom-app-using-apple-business-manager
28. Developer Program Policy - Play Console Help - Google Help, https://support.google.com/googleplay/android-developer/answer/16329168?hl=en